敏捷一開始時, 最流行的敏捷方法 (Agile Method) 是 Scrum. 根據 Scrum 的框架(如下圖所示) 你可以知道他是一個針對單一團隊的方法. 可是對於多個團隊的話, 那我們要怎麼進行敏捷呢?

圖片: Scrum Framework

Bas 和 Craig 對這件事情想破頭, 做了很多實驗, 最後才歸納出多團隊敏捷開發要怎麼進行. 他們認為多團隊要處理的事情就已經很複雜了, 開發流程不應該來火上加油, 也搞得很複雜, 這樣只是讓大家很痛苦.

因此他們重新思考了 Scrum 的本質. Scrum 的本質是在強調如何團隊成員自組織, 一起協調工作要如何分配, 接下要先做什麼才能帶給客戶價值, 如果做得不理想那要怎麼調整. 重點不是在於有哪些會議要開, 或者是有哪些角色要扮演.

我們從 Scrum 發明人 - Jeff Sutherland 所說的話中也可以得到應證.

“At its root, Scrum is based on a simple idea:
whenever you start a project, why not regularly check in, see if what you’re doing is heading in the right direction, and if it’s actually what people want?
And question whether there are any ways to improve how you’re doing what you’re doing, any ways of doing it better and faster, and what might be keeping you from doing that.”

因此, 到多團隊一起來做敏捷開發時, 要規模化的不是會議, 也不是角色. 在 Scrum 中是由產品負責人 (Product Owner) , ScrumMaster 和團隊 (developers) 所組成. 在 LeSS 中, Bas 和 Craig 認為是由 產品負責人 (Product Owner) , ScrumMaster 和一堆 Scrum 團隊所組成. 規模化 Scrum 團隊, 但是 產品負責人 (Product Owner) , ScrumMaster 盡量不規模化. 讓角色保持簡單.

另外, 要去思考如何讓”協作可以規模化”, 可以適用到多個團隊的協作, 讓他們可以有效率. 在後面我們會提到 LeSS的作法, 在流程中製造相互協作的機會, 由這些機會中學習到新的知識, 讓 LeSS 團隊變成學習性組織.

LeSS 的內容包含以下項目：

• 規則 (Rules)：定義LeSS 框架的基礎元素. 告訴你 LeSS 裡面有什麼
• 指南 (Guides)：指導你如何有效採用規則, 以及進行實驗
• 實驗 (Experiments)：在某些情境下嘗試過的作法, 當你遇到問題時, 這些實驗可以帶給你很多靈感
• 原則 (Principles)：它是從之前實驗整理出來的心法, 幫助你如何採用哪些規則

圖片來源: https://less.works/less/framework/introduction

LeSS 可以分成兩個框架

(1) LeSS 框架

• 適用於 2 - 8 Scrum 團隊一起協作
• 大約是 10 到 50 人左右
• 一個產品負責人, 所有團隊共享一份產品待辦列表
• 裡面沒有需求領域 (Requirement Area, 後面會提到) 的概念
• 組織結構會一次變革到位

圖片來源: https://less.works/less/framework

LeSS 框架是多團隊進行Scrum 的方法. 它裡面有一個產品負責人 (Product Owner), 對這些多個團隊提供產品願景, 並且對這個產品建立一個產品待辦列表 (Product Backlog), 這些多個團隊他們是共享這一份產品待辦列表. 裡面的條目的優先順序是由產品負責人決定.

每個Sprint (時間長度是在 1- 4 週內), 這些團隊能交付出整合好的, 對客戶有價值的增量 (Increment). 這些多個團隊會在Sprint時間內, 共同來開發這個產品. 這個開發過程是由Sprint所組成, 中間這些團隊會把做出來的東西整合, 最終會產生出一份增量出來.

每個Sprint是由Sprint規劃會議第一部分 (Sprint Planning 1) 開始, 他是由多個團隊公同參與的一個較短的會議, 團隊們會討論他們自己要認養, 產品待辦列表中的哪個條目. 當然我們是根據優先順序來選取, 確保最優先的條目都有人來做. 之後會進行Sprint規劃會議第二部分 (Sprint Planning 2), 各個團隊針對要如何開發這些條目, 進行必要的討論, 並且列出要進行的任務(Tasks).

接下來, 各個團隊開始進行開發工作, 條目中如果和其他團隊有關係, 他們會緊密討論和整合, 以確保在Sprint結束時, 能夠交付出可運行的產品. 這中間的討論和整合, 是團隊自行發起, 不需要由其他額外的協調者來幫忙, 這是團隊自己本身的責任.

在Sprint進行到一半時, 團隊會進行產品待辦列表的梳理會議 (Product Backlog Refinement, PBR), 和客戶或是相關的利害關係人, 一起釐清之後幾個Sprint要處理的條目內容. 這是讓團隊和客戶直接對話, 所以產品負責人可以抽出身來, 整理好故事的優先順序, 以及調整產品的願景.

在Sprint結束前, 我們會召開 Sprint Review 會議, 所有團隊和客戶一起參加, 共同對於這個Sprint所交付的東西來進行討論, 看看團隊所完成的東西, 以及決定接下來要做什麼. 然後, 每個團隊會召開 Sprint Retrospective, 檢視自己的工作內容和方式, 看看哪些地方需要進行調整. 個別團隊開完回顧會議後, 產品負責人, ScrumMaster, 管理者, 和各團隊的代表, 會來進行 整體的回顧會議(Overall Retrospective), 來討論整體或是跨團隊之間的問題.

上述的過程就是 LeSS 框架一個Sprint所要進行的事情. 和 Scrum 很像, 但是多強調了多個團隊如何協作. 並且也是利用Sprint的方式, 不斷實驗和反思, 逐漸地調整改善.

(2) LeSS Huge 框架

• 適用於 8 個團隊以上來使用
• 大約是 50 人到 6000 人左右
• 裡面會包含一些需求領域
• 每個需求領域會由一些團隊來負責, 他們會共享一份領域待辦列表
• 結構的改變是循序漸進的

圖片來源: https://less.works/less/less-huge

當有超過 8 個團隊時, 我們會採用 LeSS Huge 框架, 但是目標還是一個Sprint, 所有團隊會一起產生一份產品增量.

在 LeSS Huge 框架中, 我們會把產品切成幾個需求領域 (Requirement Area), 每個需求領域會有幾個團隊來負責, 在這個需求領域是以 LeSS 框架的方式來進行處理的.